Using log4net with NUnit

If you are like myself, you want to watch the log4net debug output while running my NUnittests. How to do it?

One interesting approach is described here.

A lighter alternative to consider, that also works nicely with NUnit GUI: make your test assembly to configure and load log4net.

1) Create an Application Configuration file for the test class library.
2) Add there log4net section, configure the logger
3) Add log4net configuration attribute to your AssemblyInfo.cs:

// Load log4net logger
[assembly: log4net.Config.XmlConfigurator(
                   ConfigFile="MyTests.config")]

Note that I renamed the auto-generated App.config to "MyTests.conf", and set it up to copy to output directory "If newer". It is a matter of the taste: you could leave App.config, and refer to it as ConfigFile="MyTestAssemblyFullName.dll.config"

PS. Is it time to move on to MBUnit?

Virtual Subversion Appliance, and Ingore Filter for C#

My working with Virtual Subversion appliance has been a breeze. I had problem with network: every time I carried my laptop between two wired and two wireless networks, it used to loss svn server. It was elegantly resolution is to switch VM network adapter settings from Bridged to Host. Now I love it: Fire VMWare Workstation (5 sec), Resume VM (1 sec) yeah, does wake up quickly! Commit changes - I am getting to like Tortoise! Suspend VM, exit VMWare. Done, and the whole svn is gone as if was never present on my computer. In fact it wasn't :-)

To the second point. Working with C# project, I got to filter out the noise when committing changes. Here is my C# ignore list:


bin
obj
*.bin
*.dll
*.exe
*.pdb
*.resources
*.suo
*.cache
*.Cache
*.force

Tip: Files work fine if separated by a blankspace. However directories should be delimited with new lines. If you use TortoiseSVN, make sure to use a new line. Click on the image to see closely.

Testing Web Service Clients

As using Web Services becomes a fashionable trend, Test Driven Developers are asking: “How do I test my application that is a Web Service Client”? On the one hand, the testing approach is not different from working with Database, file system, or 3rd party API. On the other hand, we can use WS specifics to leverage testing. Let’s take a closer look.

Consider a typical application that, as part of domain logic implementation, consumes a web service. A DomainImp class calls DomainService – a service abstraction driven by domain logic. Think Evans, Domain Driven Design, Adapter, and Dependency Inversion Principle. Domain Service resolves domain specific call into one or several calls to the Web Service. Each is calling a Web Service Proxy class, transferring a SOAP* message over wire to the target machine, and executing WebService code there.

There are 4 seams. We can mock or stub any of 1) Domain Service, 2) WS Proxy, 3) Transport service 4) WebService.

1) Mock Domain Service. This is a TDD classic: extract an interface if you don’t have it yet, and substitute a production implementation by the mock for the test. This works the best for domain unit testing, especially if calling a WS is peripheral functionality, and/or only small subset of WS is used.

2) Mock Web Service Proxy. If the use of WS is central to the application logic and unlikely to change, and/or most of Web Service methods are used, you may find the DomainService redundant. Then mock Web Service Proxy class! This is simple: extract the interface, implement a mock/stub, switch domain code to use mock/stub if unit testing. A slightly different way is explained here. BTW, if you are with Visual Studio, I recommend to copy reference.cs, rename or “namespace” WS Proxy class, and work with it. If you don’t, Refresh Web Reference command may [and eventually will] mess things up.

3) Mock a service on a transport layer. The request and response travel over the wire. It calls for a simple plan to mock it up: sniff the response, and on request just shoot it back.

a) Sniff the request/response. I use tcpTrace or proxyTrace from PocketSoap.com.

b) Bring up the mock server to take requests and shoot back responses. How about writing a trivial socket server that listens on the port and bluntly spits out the hardcoded response? Then smart it up: base the response on the request. Or make it configurable. Or... Here you scream “too much!” and are about to give up. But hold on! there is a tool, and it is cool!! SoapUI: check it out, and go straight to Mocking Web Services. Here is how I used it:

• Import a WSDL (file or URL). It generates requests to play with the actual Web Service.
  
• Generate Mock Web Service. I can have all web methods, some of them, or any combinations from all WSDLs you have imported.
  
• Right from soapUI, test my Mock to see if it works.
  
• Stick responses captured at step a). I can have many responses, control their order, even script, were I groovy savvy :(
  
• Configure my client to point to the Mock Web Service, Run, have fun.
  

4) Build a mock Web Service. In .NET case, I run wsdl /si to generate ASP.NET Web Service Interface. Alternatively, check out WSCF - Web Services Contract First http://www.thinktecture.com/resourcearchive/tools-and-software/wscf. I didn’t get to try it myself: wsdl /si worked fine for me. Then I use Visual Studio Refactoring/Generate Implementation that builds me a stab. Then I implement the mock/stab pretty much like in case of WS Proxy.
Mocking a Web Service gives a lot of control. The trouble is to build complex types. I had to make breakpoints in WebProxy while working with real WebService, intercept the responses, interrogate their data, and manually re-create them on Web Service Mock.

The methods #1 and #2 requires code changes to build the test; they are good suit for unit testing. With #3 and #4 testing is done against full “release” build, which makes them suit for black box QA tests, performance, etc. In practice I prefer #1, Mock Domain Service, for unit tests, augmented with #3, Mock a service with a tool, for acceptance, QA tests and off-line demos.

Perils of Documenting Architecture

Writing Big Architecture Document, I couldn't help thinking of a nice Russian saying. It is about translation; rephrased for architecture and translated (!), in English it becomes:

Architectural documentation is like a lady. When she is fair, she isn't pretty. When she is pretty, she isn't fair.

WCF+WF in ORCAS: Deep Dive Training at Redmond

I spent 3 days at Platform Adaptation Center in Redmond, taking a dive in hot Microsoft technologies. The focus was on Orcas, the upcoming version of Visual Studio and .NET 3.5. We also got insights of the current .NET 3.0, and features beyond ORCAS.

My professional focus was on Windows Workflow Foundation. My geeky side was fascinated by LINQ. Windows WF worths a dedicated post. For details on LINQ I’d rather refer you to someone who can tell the story: Anders Hejlsberg! Watch a video interview from here. To taste it, follow "The road to Linq: C# 3.0 for mere mortals" paved by Alex Thissen.

It is intriguing: ADO.NET team comes with Entity Framework, new and cool, along with ESQL query language. It directly competes with LINQ to SQL (aka DLINQ); and we got competing evangelists from the two competing teams presenting. The obvious question "what Microsoft’s recommendation on choosing between the two" was answered with pretty much "the jury is out".

Every time I see PowerShell, I am excited and ready to install & play & learn & use it right away. Never gotten beyond installation yet . After David Aiken’s show, I will do it. David had delivered Using Powershell to manage WF & WCF – great demo! Later he spoke about application manageability, WMI, events and their play in M$ Dynamic Systems Initiative.

Rules rulez! Moustafa Ahmed made it clear. Rehost a rules engine whenever you pleased, and what a great power. Rules Editor, on the other hand, is not so cool. Technically it is rehostable, but only developers can possibly use it. For normal users, you’re on your own.

What else? Three presentations on Windows Communication Framework. Justin Smith was talking about Syndication and later on WCF performance. Pravin Indurkar shown in-depth interplay of WCF and WF. I liked Justin’s thinking broadly of syndication, beyond blogs and news. Think of an event log as a syndication of events, a record set is syndication of data rows, a web page as a syndication of data backed controls, and so on. WCF is promising support for Atom & RSS.

AJAX: two presentations, by Steve Marx and Eugene Osovetsky, and the lab on JSON & AJAX win WCF. Workflow Driven User Interface: web application “HelpDesk” example demoed by Shelly Guo. Compact framework and Office/Sharepoint – not interested.. Federated Identity was presented in greatly understandable way by CardSpace team – now I can explain it myself! Brian Keller was showing off VS Team System. It was off-beat for the general theme, but for me both the presentation and after-talk with Brian was so interesting… I gotta blog on this separately.

The audience of around 50 was a mix of innovators from blogging and training cutting edge, on one side, and pragmatics from the dusty field of daily industrial development, on the other. Innovator Alex wanted to know where LINQ is going after ORCAS. I wanted to figure if I could use WF right now. Satisfying both sides presented a challenge to the organizers. At the end, though, both sides got their questions answered.

Overall – good organization, smart guys, great event.

OpenLazlo

A friend of mine gave me a buzz: “Check it out, OpenLaszlo”.

A free open source AJAX toolkit, OpenLazlo gives an XML based language with embedded JavaScript that compiles into Flash or DTHML. Originally optimized for FireFox, but claims full support for Internet Explorer, including 7.0. No JSON, but XML based dataset with XPath query is provided instead. Animation is OpenLaszlo’s sweet spot. Demos are sexy, and “Laszlo in 10 minutes” is fun. Although I still more like fine-grain control, like with Atlas, OpenLaszlo declarative style ramps up web development time.

Morale: AJAX is cool, Open Source rules, friends matter.